In a conventional distributed object computing system, such as that illustrated in FIG. 1, a client program 104, operating in a client computer 100, often makes a method call on a remote object 108 located in a server computer 102 by means of a reference 106 to that object 108. Specifically, the client program 104 makes a method call on the reference 106 as indicated schematically by arrow 110. The reference 106, in turn, marshals any parameters involved in the call, initiates contact with the remote object 108, makes the method call on that object as indicated schematically by arrow 114. If a response is returned from the remote object 108, as indicated schematically by arrow 116, the reference 106 un-marshals any return values and returns the response to the client 104 as indicated schematically by arrow 112.
In order to operate in this manner, the reference 106 must be able to locate the remote object 108 to which it refers. In standard remote procedure call systems, like Java™ RMI (Java is a trademark of Sun Microsystems, Inc.) or CORBA, the simplest form of reference 106 contains a record of the machine 102 on which the remote object 108 resides and the port number on which that object 108 is listening for method calls. More complex references in such remote procedure call systems, such as those that allow object activation, include not only a reference containing a machine and port number (sometimes called an “active reference”) but also a secondary reference to some object that, if a method call to the active reference fails because the remote object cannot be located, can be contacted to obtain a more current active reference to the original remote object (obtained, perhaps, by actually starting up that object). This secondary reference is also called an active reference, but it is an active reference to a different object that is assumed to be highly available. Thus, even this secondary reference contains information that ties that reference to a particular location on the network.
These conventional remote procedure call mechanisms closely tie the identity of a remote object 108 with the location of that object (or the location of a third-party object, which in turn can locate the referenced object). Such mechanisms only work for remote objects 108 that stay in one location. If the object 108 is moved to a different machine, the reference 106 will be unable to determine the machine on which the remote object 108 now resides, and thus will be unable to make a method call on the object 108. There have been proposals to allow such object movement if the remote object 108 leaves behind a forwarding address (sometimes called a “tombstone”), but even these mechanisms will fail if the machine 102 contained in the active reference no longer exists (or, more precisely, no longer exists on the network).
Some systems must deal with remote objects that are moved over their lifetime and which may be moved from a machine that is later disconnected from the network. Thus, there is a need for a reference to a remote object that will allow a client to find that object even if the object has been moved. Further, since the reference cannot be assured of being informed at the time the object is moved; the reference must be able to determine that an object has moved and what the new location of an object is when that object is needed.